Learned a few things about xdg and mimetype registration in the last week that could be helpful to have condensed in a single place. No Need to Ship a Mailcap Mime File If you already ship a .desktop file (that is what ends up in /usr/share/applications/) which has a MimeType declared, there is no need to also ship a mailcap file (that is what ends up in /usr/lib/mime/packages/). Some triggers will do the conversion work for you. See also Debian Policy 4.9. Reverse DNS Naming Convention for .desktop Files Seems to be a closely guarded secret, maybe mainly known inside the Gnome world, but it's in the spec. Also not very widely known inside Debian if I look at my local system as not very representative sample. Your hicolor Theme App Icon can be a Mime Type Icon as Well In case you didn't know the hicolor icon theme is the default fallback theme. Many of us already install application icons e.g. in /usr/share/icons/hicolor/48x48/apps/ which is used in conjunction with the Icon field in the .desktop file to locate the application icon. Now the next step, and there it seems quite of few us miss out, is to create a symlink to also provide a mime type icon, so it's displayed in graphical file managers for the application data files. The schema here is simple: Take the MimeType e.g. application/x-vymand replace the / with a - and use that as file name in e.g. /usr/share/icons/hicolor/48x48/mimetypes/. In the vym case that is /usr/share/icons/hicolor/48x48/mimetypes/application-x-vym.png. If you have one use a scalable .svg file instead of .png. This seems to be an area where Debian lacks a bit of tooling to automatically convert application icons to all the different sizes and install it in all the appropriate places. What is already there is a trigger to run gtk-update-icon-cache when you install new icons into one of the icon theme folder so they're picked up. No Priority or Order in .desktop Files Likely something that hapens on all my fresh installations: Libreoffice is installed and xdg-open starts to open pdf files with Libreoffice instead of evince. Now I've to figure out again to run xdg-mime default org.gnome.Evince.desktop application/pdf to change that (at least for my user). Background here is that the desktop file spec explicitly mandates "Priority for applications is handled external to the .desktop files.". That's why we got in addition to all of that mimeapps.list files. And now, after running the xdg-mime command from above, we've a ~/.config/mimeapps.list defining

[Default Applications]
application/pdf=org.gnome.Evince.desktop

Debian as whole seems to be not very keen on shipping something like a sensible default mimeapps.list outside of desktop environment specific ones. A quick search gave me just

$ apt-file search mimeapps.list
cinnamon-desktop-data: /usr/share/applications/x-cinnamon-mimeapps.list
gdm3: /usr/share/gdm/greeter/applications/mimeapps.list
gnome-session-common: /usr/share/applications/gnome-mimeapps.list
plasma-workspace: /usr/share/applications/kde-mimeapps.list
sxmo-utils: /usr/share/applications/mimeapps.list
sxmo-utils: /usr/share/sxmo/xdg/mimeapps.list

While it's a bit anoying to run into that pdf vs Libreoffice thing every now and then, it's maybe better to not have long controversial threads about default pdf viewer, like the ones we already had about the default MTA choices. And while we're at it: everyone using Libreoffice should give a virtual hug to rene@ for taming that beast since 2010 and OpenOffice.org before.

Had a need for a mindmapping application and found view your mind in the archive. Works but the version is a bit rusty. Sadly my Debian packaging skills are a bit rusty as well, especially when it comes to bigger GUI applications. Thus I spent a good chunk of yesterday afternoon to rip out cdbs and package the last source release on github which is right now 2.9.22 (the release branch already has 2.9.27, still sorting that out). Git repository and a amd64 build of the current state. It still deserves some additional love, e.g. creating a -common package for arch indep content. Proposed a few changes upstream:

• spelling fixes
• .desktop file improvements
• small adjustments for the documentation installation via cmake

Also pinged pollux@ who uploaded vym up to 2019 if he'd be fine if I pick it up. If someone else is interested, I'm also fine to put it up on salsa in the general "Debian" group for shared maintenance. I guess I will use it in the future, but time is still a scarce resource for all of us.

I recently came a cross a x509 P(rivate)KI Root Certificate which had a pathLen constrain set on the (self signed) Root Certificate. Since that is not commonly seen I looked a bit around to get a better understanding about how the pathLen basic constrain should be used. Primary source is RFC 5280 section 4.2.1.9

The pathLenConstraint field is meaningful only if the cA boolean is asserted and the key usage extension, if present, asserts the keyCertSign bit (Section 4.2.1.3). In this case, it gives the maximum number of non-self-issued intermediate certificates that may follow this certificate in a valid certification path

Since the Root is always self-issued it doesn't count towards the limit, and since it's the last certificate (or the first depending on how you count) in a chain, it's pretty much pointless to configure a pathLen constrain directly on a Root Certificate. Another relevant resource are the Baseline Requirements of the CA/Browser Forum (currently v2.0.2). Section 7.1.2.1.4 "Root CA Basic Constraints" describes it as NOT RECOMMENDED for a Root CA. Last but not least there is the awesome x509 Limbo project which has a section for validating pathLen constrains. Since the RFC 5280 based assumption is that self signed certs do not count, they do not check a case with such a constrain on the Root itself, and what the implementations do about it. So the assumption right now is that they properly ignore it. Summary: It's pointless to set the pathLen constrain on the Root Certificate, so just don't do it.

Write it down before I forget about it again:

for x in $(gh api graphql --paginate -f query='query($endCursor:String)   organization(login:"myorg")  
    repositories(first: 100, after: $endCursor, isArchived:false)  
        pageInfo  
            hasNextPage
            endCursor
         
        nodes  
            name
         
     
     
     ' --jq '.data.organization.repositories.nodes[].name'); do
    secrets=$(gh secret list --json name --jq '.[].name' -R "myorg/$ x "   tr '\n' ',')
    if ! [ -z "$ secrets " ]; then
        echo "$ x ,$ secrets "
    fi
done

Requests a list of all not archived repositories in a GitHub org and queries repository secrets. If we find some we output the repo name and the secrets in a comma separated list. Not real CSV, but good enough for further processing. I've to admit it's kinda beautiful what you can do with the gh cli by now. Sadly it seems the secrets are not yet available via GraphQL (or I missed it in the docs), so I just use the gh cli to do the REST calls.

I stick to some very archaic workflows, e.g. to connect to some corp VPN I just run sudo vpnc-connect and later on sudo vpnc-disconnect. In the past that also managed to restore my resolv.conf, currently it doesn't. According to a colleague that's also the case for Ubuntu. Taking a step back, the sane way would be to use the NetworkManager vpnc plugin, but that does not work with this specific case because we use uncool VPN tech which requires the Enable weak authentication setting for vpnc. There is a feature request open for that one at https://gitlab.gnome.org/GNOME/NetworkManager-vpnc/-/issues/11 Taking another step back I thought that it shouldn't be that hard to add some checkbox, a boolean and render out another config flag or line in a config file. Not as intuitive as I thought this mix of XML and C. So let's quickly look elsewhere. What happens is that the backup files in /var/run/vpnc/ are created by the vpnc-scripts script called vpnc-script, but not moved back, because it adds some pid as a suffix and the pid is not the final pid of the vpnc process. Basically it can not find the backup when it tries to restore it. So I decided to replace the pid guessing code with a suffix made up of the gateway IP and the tun interface name. No idea if that is stable in all circumstance (someone with a vpn name DNS RR?) or several connections to different gateways. But good enough for myself, so here is my patch:

vpnc-scripts [master]$ cat debian/patches/replace-pid-detection 
Index: vpnc-scripts/vpnc-script
===================================================================
--- vpnc-scripts.orig/vpnc-script
+++ vpnc-scripts/vpnc-script
@@ -91,21 +91,15 @@ OS=" uname -s "
 HOOKS_DIR=/etc/vpnc
-# Use the PID of the controlling process (vpnc or OpenConnect) to
-# uniquely identify this VPN connection. Normally, the parent process
-# is a shell, and the grandparent's PID is the relevant one.
-# OpenConnect v9.0+ provides VPNPID, so we don't need to determine it.
-if [ -z "$VPNPID" ]; then
-    VPNPID=$PPID
-    PCMD= ps -c -o cmd= -p $PPID 
-    case "$PCMD" in
-        *sh) VPNPID= ps -o ppid= -p $PPID  ;;
-    esac
+# This whole script is called twice via vpnc-connect. On the first run
+# the variables are empty. Catch that and move on when they're there.
+if [ -n "$VPNGATEWAY" ]; then
+    BACKUPID="$ VPNGATEWAY _$ TUNDEV "
+    DEFAULT_ROUTE_FILE=/var/run/vpnc/defaultroute.$ BACKUPID 
+    DEFAULT_ROUTE_FILE_IPV6=/var/run/vpnc/defaultroute_ipv6.$ BACKUPID 
+    RESOLV_CONF_BACKUP=/var/run/vpnc/resolv.conf-backup.$ BACKUPID 
 fi
-DEFAULT_ROUTE_FILE=/var/run/vpnc/defaultroute.$ VPNPID 
-DEFAULT_ROUTE_FILE_IPV6=/var/run/vpnc/defaultroute_ipv6.$ VPNPID 
-RESOLV_CONF_BACKUP=/var/run/vpnc/resolv.conf-backup.$ VPNPID 
 SCRIPTNAME= basename $0 
 # some systems, eg. Darwin & FreeBSD, prune /var/run on boot

Or rolled into a debian package at https://sven.stormbind.net/debian/vpnc-scripts/ The colleague decided to stick to NetworkManager, moved the vpnc binary aside and added a wrapper which invokes vpnc with --enable-weak-authentication. The beauty is, all of this will break on updates, so at some point someone has to understand GTK4 to fix the NetworkManager plugin for good.

Always amusing to see some more or less famous open source tools on stage or in movies. Lately we watched THE ME (german only) which is mixing live playing of actors and pre recorded video material. In one of the early video sequences a fictional console interface is displayed, claiming to be running on a Macbook, and htop is used to look for a suspicious process.

PSA for those foolish enough to use Google Cloud and try to use private service connect: If you want to change the serviceAttachment your private service connect forwarding rule points at, you must delete the forwarding rule and create a new one. Updates are not supported. I've done that in the past via terraform, but lately encountered strange errors like this:

Error updating ForwardingRule: googleapi: Error 400: Invalid value for field 'target.target':
'<https://www.googleapis.com/compute/v1/projects/mydumbproject/regions/europe-west1/serviceAttachments/
k8s1-sa-xyz-abc>'. Unexpected resource collection 'serviceAttachments'., invalid

Worked around that with the help of terrraform_data and lifecycle:

resource "terraform_data" "replacement"  
    input = var.gcp_psc_data["target"]
 
resource "google_compute_forwarding_rule" "this"  
    count   = length(var.gcp_psc_data["target"]) > 0 ? 1 : 0
    name    = "$ var.gcp_psc_name -psc"
    region  = var.gcp_region
    project = var.gcp_project
    target                = var.gcp_psc_data["target"]
    load_balancing_scheme = "" # need to override EXTERNAL default when target is a service attachment
    network               = var.gcp_network
    ip_address            = google_compute_address.this.id
    lifecycle  
        replace_triggered_by = [
            terraform_data.replacement
        ]
     
 

See also terraform data for replace_triggered_by.

In my day job someone today took the time in the team daily to explain his research why some of our configuration is wrong. He spent quite some time on his own to look at the history in git and how everything was setup initially, and ended up in the current - wrong - way. That triggered me to validate that quickly, another 5min of work. So we agreed to change it. A one line change, nothing spectacular, but lifetime was invested to figure out why it should've a different value. When the pull request got opened a few minutes later there was nothing of that story in the commit message. Zero, nada, nothing. I'm really puzzled why someone invests lifetime to dig into company internal history to try get something right, do a lengthy explanation to the whole team, use the time of others, even mention that there was no explanation of why it's not the default value anymore it should be, and repeat the same mistake by not writing down anything in the commit message. For the current company I'm inclined to propose a commit message validator. For a potential future company I might join, I guess I ask for real world git logs from repositories I should contribute to. Seems that this is another valuable source of information to qualify the company culture. Next up to the existence of whiteboards in the office. I'm really happy that at least a majority of the people contributing to Debian writes somewhat decent commit messages and changelogs. Let that be a reminder to myself to improve in that area the next time I've to change something.

I know a few people hold on to the exFAT fuse implementation due the support for timezone offsets, so here is a small update for you. Andrew released 1.4.0, which includes the timezone offset support, which was so far only part of the git master branch. It also fixes a, from my point of view very minor, security issue CVE-2022-29973. In addition to that it's the first build with fuse3 support. If you still use this driver, pick it up in experimental (we're in the bookworm freeze right now), and give it a try. I'm personally not using it anymore beyond a very basic "does it mount" test.

While my first impression of Guix 1.4rc2 on NV41PZ was only days ago, the final Guix 1.4 release has happened. I thought I should give it a second try, although being at my summer house with no wired ethernet I realized this may be overly optimistic. However I am happy to say that a guided graphical installation on my new laptop went smooth without any problem. Practicing OS installations has a tendency to make problems disappear. My WiFi issues last time was probably due to a user interface mistake on my part: you have to press a button to search for wireless networks before seeing them. I m not sure why I missed this the first time, but maybe the reason was that I didn t really expect WiFi to work on this laptop with one Intel-based WiFi card without firmware and a USB-based WiFi dongle. I haven t went back to the rc2 image, but I strongly believe it wasn t a problem with that image but my user mistake. Perhaps some more visual clues could be given that Guix found a usable WiFi interface, as this isn t completely obvious now. My main pet problem with the installation is the language menu. It contains a bazillion languages, and I want to find Swedish in it. However the list is half-sorted so it looks like it is alphabetized but paging through the list I didn t find svenska , but did notice that the sorting restarts after a while. Eventually I find my language of chose, but a better search interface would be better. Typing s to find it jumps around in the list. This may be a user interface misunderstanding on my part: I may be missing whatever great logic I m sure there is to find my language in that menu. I did a simple installation, enabling GNOME, Cups and OpenSSH. Given the experience with sharing /home with my Trisquel installation last time, I chose to not mount it this time, fixing this later on if I want to share files between OSes. Watching the installation proceed with downloading packages over this slow WiFi was meditative, and I couldn t help but wonder what logic there was to the many steps where it says it is going to download X MB of software, downloads a set of packages, and then starts another iteration saying it is going to download Y MB and then downloads another set of packages. Maybe there is a package dependency tree being worked out while I watch. After logging into GNOME I had to provide the WiFi password another time, it seems it wasn t saved during installation, or I was too impatient to wait for WiFi to come up automatically. Using the GNOME WiFi selection menu worked fine. The webcam issue is still present, the image is distorted and it doesn t happen in Trisquel. Other than that, everythings appear to work, but it has to be put through more testing. Upgrading Guix after installation is still suffering from the same issue I noticed with the rc2 images, this time I managed to save the error message in case someone wants to provide an official fix or workaround. The initial guix pull command also takes forever, even on this speedy laptop, but after the initial run it is faster. Here are the error messages (pardon the Swedish):

jas@kaka ~$ sudo -i
...
root@kaka ~# guix pull
...
root@kaka ~# guix system reconfigure /etc/config.scm 
guix system: fel: aborting reconfiguration because commit 8e2f32cee982d42a79e53fc1e9aa7b8ff0514714 of channel 'guix' is not a descendant of 989a3916dc8967bcb7275f10452f89bc6c3389cc
tips: Use  --allow-downgrades' to force this downgrade.
root@kaka ~# 

I ll avoid using allow-downgrades this time to see if there is a better solution available. Update: Problem resolved: my muscle memory typed sudo -i before writing the commands above. If I stick to the suggested guix pull (as user) followed by sudo guix system reconfigure /etc/config.scm everything works. I ll leave this in case someone else runs into this problem. I m using the Evolution mail/calendar/contacts application, and it was not installed via GNOME so I had to manually install it using guix package -i evolution . Following the guided setup worked remarkable well (it auto-detects all my email settings after giving it my email address), although at the end I get a surprising error message:

Puzzling error message from Evolution

If I didn t know a bit about how Evolution works internally, I would have been stuck here the solution is to install the evolution data server package. This should probably be a dependency from the main package? Fix it by guix package -i evolution-data-server . It works directly, no need to even restart Evolution or go through the configuration dialog again. After this, I m happily using email against my Dovecot server and contacts/calendars against my Nextcloud server via GNOME s builtin Nextcloud connector which was straight-forward to setup.

tl;dr; OpenSSL 3.0.1 leaks memory in ssl3_setup_write_buffer(), seems to be fixed in 3.0.5 3.0.2. The issue manifests at least in stunnel and keepalived on CentOS 9. In addition I learned the hard way that running a not so recent VirtualBox version on Debian bullseye let to dh parameter generation crashing in libcrypto in bn_sqr8x_internal(). A recent rabbit hole I went down. The actual bug in openssl was nailed down and documented by Quentin Armitage on GitHub in keepalived My bugreport with all back and forth in the RedHat Bugzilla is #2128412. Act I - Hello stunnel, this is the OOMkiller Calling We started to use stunnel on Google Cloud compute engine instances running CentOS 9. The loadbalancer in front of those instances used a TCP health check to validate the backend availability. A day or so later the stunnel instances got killed by the OOMkiller. Restarting stunnel and looking into /proc/<pid>/smaps showed a heap segment growing quite quickly. Act II - Reproducing the Issue While I'm not the biggest fan of VirtualBox and Vagrant I've to admit it's quite nice to just fire up a VM image, and give other people a chance to recreate that setup as well. Since VirtualBox is no longer released with Debian/stable I just recompiled what was available in unstable at the time of the bullseye release, and used that. That enabled me now to just start a CentOS 9 VM, setup stunnel with a minimal config, grab netcat and a for loop and watch the memory grow. E.g. while true; do nc -z localhost 2600; sleep 1; done To my surprise, in addition to the memory leak, I also observed some crashes but did not yet care too much about those. Act III - Wrong Suspect, a Workaround and Bugreporting Of course the first idea was that something must be wrong in stunnel itself. But I could not find any recent bugreports. My assumption is that there are still a few people around using CentOS and stunnel, so someone else should probably have seen it before. Just to be sure I recompiled the latest stunnel package from Fedora. Didn't change anything. Next I recompiled it without almost all the patches Fedora/RedHat carries. Nope, no progress. Next idea: Maybe this is related to the fact that we do not initiate a TLS context after connecting? So we changed the test case from nc to openssl s_client, and the loadbalancer healthcheck from TCP to a TLS based one. Tada, a workaround, no more memory leaking. In addition I gave Fedora a try (they have Vagrant Virtualbox images in the "Cloud" Spin, e.g. here for Fedora 36) and my local Debian installation a try. No leaks experienced on both. Next I reported #2128412. Act IV - Crash in libcrypto and a VirtualBox Bug When I moved with the test case from the Google Cloud compute instance to my local VM I encountered some crashes. That morphed into a real problem when I started to run stunnel with gdb and valgrind. All crashes happened in libcrypto bn_sqr8x_internal() when generating new dh parameter (stunnel does that for you if you do not use static dh parameter). I quickly worked around that by generating static dh parameter for stunnel. After some back and forth I suspected VirtualBox as the culprit. Recompiling the current VirtualBox version (6.1.38-dfsg-3) from unstable on bullseye works without any changes. Upgrading actually fixed that issue. Epilog I highly appreciate that RedHat, with all the bashing around the future of CentOS, still works on community contributed bugreports. My kudos go to Clemens Lang. Now that the root cause is clear, I guess RedHat will push out a fix for the openssl 3.0.1 based release they have in RHEL/CentOS 9. Until that is available at least stunnel and keepalived are known to be affected. If you run stunnel on something public it's not that pretty, because already a low rate of TCP connections will result in a DoS condition.

Here s my (thirty-sixth) monthly but brief update about the activities I ve done in the F/L/OSS world.

Debian

This was my 45th month of actively contributing to Debian. I became a DM in late March 2019 and a DD on Christmas 19! \o/ There s a bunch of things I do, both, technical and non-technical. Here are the things I did this month:

Debian Uploads

• rails (2:6.1.6.1+dfsg-2) - Add patch to allow Symbols in YAML columns, fixes #1018934.
• rails (2:6.1.6.1+dfsg-3) - Add patch to remove active_record.yaml initializers.
• rails (2:6.1.6.1+dfsg-4) - Add patch to allow Date, Time, ActiveSupport::HashWithIndifferentAccess in YAML columns.
• ruby-arbre (1.4.0-2) - Add patch to use selector to detect authenticity token input.
• ruby-net-http-digest-auth (1.4.1-1) - New upstream version, v1.4.1 to fix the FTBFS w/ rails.
• rails (2:6.1.7+dfsg-1) - New upstream version, v6.1.7+dfsg.
• redmine (5.0.2-1) - New upstream version, v5.0.2 + fixes for #1017525, #1019607, #1019238, and #1014813.
• redmine (5.0.2-2) - Add patch to relax pg s version for autopkgtest.
• ruby-json-jwt (1.14.0-2) - No-change rebuild for unstable to fix #1011682.
• libexporter-tiny-perl (1.004002-1) - New upstream version, v1.004002.

Other $things:

• Sponsored php-nikic-fast-route/1.3.0-4~bpo11+1 for William.
• Being an AM for Arun Kumar, process #1024.
• Sponsoring stuff for non-DDs.
• Mentoring for newcomers.
• Moderation of -project mailing list.

---

Ubuntu

This was my 20th month of actively contributing to Ubuntu. Now that I joined Canonical to work on Ubuntu full-time, there s a bunch of things I do! \o/ I mostly worked on different things, I guess. I was too lazy to maintain a list of things I worked on so there s no concrete list atm. Maybe I ll get back to this section later or will start to list stuff from the fall, as I was doing before. :D

---

Debian (E)LTS

Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years. Debian LTS is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success. And Debian Extended LTS (ELTS) is its sister project, extending support to the Jessie release (+2 years after LTS support). This was my thirty-sixth month as a Debian LTS and twenty-seventh month as a Debian ELTS paid contributor.
I worked for 38.00 hours for LTS and 27.00 hours for ELTS.

LTS CVE Fixes and Announcements:

• Rolled out announcement for src:flac.
• Rolled out announcement for src:ruby-rack.
• Issued DLA 3128-1, fixing CVE-2020-7677, for node-thenify.
  For Debian 10 buster, these problems have been fixed in version 3.3.0-1+deb10u1.
• Issued DLA 3129-1, fixing CVE-2019-17545 and CVE-2021-45943, for gdal.
  For Debian 10 buster, these problems have been fixed in version 2.4.0+dfsg-1+deb10u1.
• Looked at src:mbedtls which has about 18 CVEs opened in buster (including no-dsa).
  Also, spoke to the maintainer - they said they d be uncomfortable doing or reviewing the backport (although they initially said they d be happy to help).
• Fixed src:rails regression via 2:6.1.6.1+dfsg-2, 2:6.1.6.1+dfsg-3, and 2:6.1.6.1+dfsg-4 for sid.
  CVE-2022-32224 broke the entire world. :)
• Helped Abhijith figure out the regression fix for CVE-2022-32224.
  Also got that verified by the people who reported regression, Raphael, Sven, and Jude. The whole thread is on debian-lts@.

ELTS CVE Fixes and Announcements:

• Rolled out announcemnet for src:ruby-tzinfo.
• Rolled out announcemnet for src:grubt.
• Issued ELA 682-1, fixing CVE-2022-31676, for open-vm-tools.
  For Debian 9 stretch, these problems have been fixed in version 2:10.1.5-5055683-4+deb9u3.
• Issued ELA 691-1, fixing CVE-2020-21365, for wkhtmltopdf.
  For Debian 8 jessie, these problems have been fixed in version 0.12.1-2+deb8u1.
  For Debian 9 stretch, these problems have been fixed in version 0.12.3.2-3+deb9u1.
• Issued ELA 692-1, fixing CVE-2022-37452, for exim4.
  For Debian 8 jessie, these problems have been fixed in version 4.84.2-2+deb8u9.
  For Debian 9 stretch, these problems have been fixed in version 4.89-2+deb9u9.
• Started to look at src:tiff again. Has a lot of open issues. Haven t claimed the package officially yet, though. :)

Other (E)LTS Work:

• Triaged rails, node-thenify, exim4, wkhtmltopdf, gdal, and mbedtls.
• Marked CVE-2019-25050/gdal as not-affected for buster.
• Marked CVE-2022-37451/exim4 as not-affected for stretch and jessie; following buster and bullseye.
• Helped and assisted new contributors joining Freexian (LTS/ELTS).
• Answered questions (& discussions) on IRC (#debian-lts and #debian-elts) and Matrix.
• Participated and helped fellow members with their queries via private mail and chat.
• General and other discussions on LTS private and public mailing list.
• Attended the monthly public meeting held on #debian-lts on September 29th.

---

Until next time.
:wq for today.

Update of my notes from 2020.

# Download a binary device tree file and matching kernel a good soul uploaded to github
wget https://github.com/vfdev-5/qemu-rpi2-vexpress/raw/master/kernel-qemu-4.4.1-vexpress
wget https://github.com/vfdev-5/qemu-rpi2-vexpress/raw/master/vexpress-v2p-ca15-tc1.dtb
# Download the official Rasbian image without X
wget https://downloads.raspberrypi.org/raspios_lite_armhf/images/raspios_lite_armhf-2022-04-07/2022-04-04-raspios-bullseye-armhf-lite.img.xz
unxz 2022-04-04-raspios-bullseye-armhf-lite.img.xz
# Convert it from the raw image to a qcow2 image and add some space
qemu-img convert -f raw -O qcow2 2022-04-04-raspios-bullseye-armhf-lite.img rasbian.qcow2
qemu-img resize rasbian.qcow2 4G
# make sure we get a user account setup
echo "me:$(echo 'test123' openssl passwd -6 -stdin)" > userconf
sudo guestmount -a rasbian.qcow2 -m /dev/sda1 /mnt
sudo mv userconf /mnt
sudo guestunmount /mnt
# start qemu
qemu-system-arm -m 2048M -M vexpress-a15 -cpu cortex-a15 \
 -kernel kernel-qemu-4.4.1-vexpress -no-reboot \
 -smp 2 -serial stdio \
 -dtb vexpress-v2p-ca15-tc1.dtb -sd rasbian.qcow2 \
 -append "root=/dev/mmcblk0p2 rw rootfstype=ext4 console=ttyAMA0,15200 loglevel=8" \
 -nic user,hostfwd=tcp::5555-:22
# login at the serial console as user me with password test123
sudo -i
# enable ssh
systemctl enable ssh
systemctl start ssh
# resize partition and filesystem
parted /dev/mmcblk0 resizepart 2 100%
resize2fs /dev/mmcblk0p2

Now I can login via ssh and start to play:

ssh me@localhost -p 5555

tl;dr I ported a part of the python-suntime library to Lua to use it on OpenWRT and RutOS powered devices. suntime.lua There are those unremarkable things which let you pause for a moment, and realize what a great gift of our time open source software and open knowledge is. At some point in time someone figured out how to calculate the sunrise and sunset time on the current date for your location. Someone else wrote that up and probably again a different person published it on the internet. The Internet Archive preserved a copy of it so I can still link to it. Someone took this algorithm and published a code sample on StackOverflow, which was later on used by the SatAgro guys to create the python-suntime library. Now I could come along, copy the core function of this library, convert it within a few hours - mostly spent learning a bit of Lua, to a working script fulfilling my needs.

Sometimes it's nice for testing purpose to have the OpenWRT userland available locally. Since there is an x86 build available one can just run it within qemu.

wget https://downloads.openwrt.org/releases/21.02.1/targets/x86/64/openwrt-21.02.1-x86-64-generic-squashfs-combined.img.gz
gunzip openwrt-21.02.1-x86-64-generic-squashfs-combined.img.gz
qemu-img convert -f raw -O qcow2 openwrt-21.02.1-x86-64-generic-squashfs-combined.img openwrt-21.02.1.qcow2
qemu-img resize openwrt-21.02.1.qcow2 200M
qemu-system-x86_64 -M q35 \
  -drive file=openwrt-21.02.1.qcow2,id=d0,if=none,bus=0,unit=0 \
  -device ide-hd,drive=d0,bus=ide.0 -nic user,hostfwd=tcp::5556-:22
# you've to change the network configuration to retrieve an IP via
# dhcp for the lan bridge br-lan
vi /etc/config/network
  - change option proto 'static' to 'dhcp'
  - remove IP address and netmask setting
/etc/init.d/network restart
# now you should've an ip out of 10.0.2.0/24
ssh root@localhost -p 5556
# remember ICMP does not work but otherwise you should have
# IP networking available
opkg update
opkg install curl

Wasted quite some hours until I found a working Modeline in this stack exchange post so the ThinkPad works with a HDMI attached Samsung QHD display. Internal display of the ThinkPad is a FHD display detected as eDP-1, the external one is DP-3 and according to the packaging known by Samsung as S24A600NWU. The auto deteced EDID modes for QHD - 2560x1440 - did not work at all, the display simply stays dark. After a lot of back and forth with the i915 driver vs nouveau vs nvidia/nvidia-drm with and without modesetting, the following Modeline did the magic:

xrandr --newmode 2560x1440_54.97  221.00  2560 2608 2640 2720  1440 1443 1447 1478  +HSync -VSync
xrandr --addmode DP-3 2560x1440_54.97
xrandr --output DP-3 --mode 2560x1440_54.97 --right-of eDP-1 --primary

Modelines for 50Hz and 60Hz generated with cvt 2560 1440 60 did not work, neither did the one extracted with edid-decode -X from the hex blob found in .local/share/xorg/Xorg.0.log. From the auto-detected Modelines FHD - 1920x1080 - did work. In case someone struggles with a similar setup, that might be a starting point. Fun part, if I attach my several years old Dell E7470 everything is just fine out of the box. But that one just has an Intel GPU and not the unholy combination I've here:

$ lspci grep -E "VGA 3D"
00:02.0 VGA compatible controller: Intel Corporation CometLake-H GT2 [UHD Graphics] (rev 05)
01:00.0 3D controller: NVIDIA Corporation GP107GLM [Quadro P620] (rev ff)

Some time ago I looked briefly at an Envertech data logger for small scale photovoltaic setups. Turned out that PV inverter are kinda unreliable, and you really have to monitor them to notice downtimes and defects. Since my pal shot for a quick win I've cobbled together another Python script to query the portal at www.envertecportal.com, and report back if the generated power is down to 0. The script is currently run on a vserver via cron and reports back via the system MTA. So yeah, you need to have something like that already at hand. Script and Configuration You've to provide your PV systems location with latitude and longitude so the script can calculate (via python3-suntime) the sunrise and sunset times. At the location we deal with we expect to generate some power at least from sunrise + 1h to sunet - 1h. That is tunable via the configuration option toleranceSeconds. Retrieving the stationId is a bit ugly because it's not provided via any API, instead it's rendered serverside into the website. So I just logged in on the portal and picked it up by looking into the page source. www.envertecportal.com API I guess this is some classic in the IoT land, but neither the documentation provided on the portal frontpage as docx, nor the API docs at port 8090 are complete and correct. The few bits I gathered via the Firefox Web Developer Tools are:

1. Login https://www.envertecportal.com/apiaccount/login - POST, sent userName and pwd containing your login name and password. The response JSON is very explicit if your login was not successful and why.
2. Store the session cookie called ASP.NET_SessionId for use on all subsequent requests.
3. Retrieve station info https://www.envertecportal.com/ApiStations/getStationInfo - POST, sent ASP.NET_SessionId and stationId with the ID of the station. Returns a JSON with an object named Data. The field Power contains the currently generated power as a float with two digits (e.g. 0.01).
4. Logout https://www.envertecportal.com/apiAccount/Logout - POST, sent ASP.NET_SessionId.

Some Surprises There were a few surprises, maybe they help others dealing with an Envertech setup.

1. The portal truncates passwords at 16 chars.
2. The "Forget Password?" function mails you back the password in plain text (that's how I learned about 1.).
3. The login API endpoint reporting the exact reason why the login failed is somewhat out of fashion. Though this one is probably not a credential stuffing target because there is no money to make, so don't care.
4. The data logger reports the data to www.envertecportal.com at port 10013.
5. There is some checksuming done on the reported data, but the system is not replay safe. So you can sent it any valid data string at a later time and get wrong data recorded.
6. People at forum.fhem.de decoded some values but could not figure out the checksuming so far.

Here s my (twentieth) monthly update about the activities I ve done in the F/L/OSS world.

Debian

This was my 29th month of actively contributing to Debian. I became a DM in late March 2019 and a DD on Christmas 19! \o/ Interesting month, surprisingly. Lots of things happening and lots of moving parts; becoming the new normal , I believe. Anyhow, working on Ubuntu full-time has its own advantage and one of them is being able to work on Debian stuff! So whilst I couldn t upload a lot of packages because of the freeze, here s what I worked on:

Uploads and bug fixes:

• ruby-rack-cors (1.0.2-1+deb10u1) - Fix for CVE-2019-18978/#944849.
• rails (2:6.0.3.7+dfsg-1) - New upstream version, fixing CVE-2021-22904, CVE-2021-22902, and CVE-2021-22885 /#988214.
• ruby-marcel (1.0.1+dfsg-2) - Upload to unstable for rails.
• python-aws-requests-auth (0.4.3-2) - Enable build-time tests.
• gist (6.0.0-2) - Add patch to skip test when $HTTP_PROXY isn t set.
• php-cache-lite (1.8.3-1) - New upstream version, fixing FTBFS w/ PHP 8.0.
• Sponsored upload of htmldoc (1.9.3-1+deb10u1) to buster-pu, fixing CVE-2019-19630 and CVE-2021-20308 for H vard Flaget Aasen.
• Sponsored upload of libbusiness-us-usps-webtools-perl (1.125-1) to unstable, fixing #988330 for Yadd.
• Sponsored upload of radsecproxy (1.8.2-4) to unstable, fixing CVE-2021-32642 for Sven Hartge.

Other $things:

• Mentoring for newcomers and assisting people in BSP.
• Moderation of -project mailing list.

---

Ubuntu

This was my 4th month of actively contributing to Ubuntu. Now that I ve joined Canonical to work on Ubuntu full-time, there s a bunch of things I do! \o/ This month, by all means, was dedicated mostly to PHP 8.0, transitioning from PHP 7.4 to 8.0. Naturally, it had so many moving parts and moments of utmost frustration, shared w/ Bryce. :D So even though I can t upload anything, I worked on the following stuff & asked for sponsorship.
But before, I d like to take a moment to stress how kind and awesome Gianfranco Costamagna, a.k.a. LocutusOfBorg is! He s been sponsoring a bunch of my things & helping with re-triggers, et al. Thanks a bunch, Gianfranco; beers on me whenever we meet!

Merges:

• [2021-05-05] ruby2.7 (2.7.3-2ubuntu1).
• [2021-05-11] exim4 (4.94.2-2ubuntu1).
• [2021-05-17] openvpn (2.5.1-3ubuntu1).
• [2021-05-19] autofs (5.1.7-1).
• [2021-05-25] xterm (366-1ubuntu1).

Uploads & Syncs:

• [2021-05-20] php-net-url2/2.2.1-0.2build2 - no-change rebuild.
• [2021-05-26] phpmyadmin/4:5.0.4+dfsg2-2ubuntu1 - fix build w/ PHP 8.
• [2021-05-26] php-async-aws-core/1.7.2-1build1 - no-change rebuild.
• [2021-05-26] php-async-aws-ses/1.3.0-1build1 - no-change rebuild.
• [2021-05-26] php-async-aws-sqs/1.3.2-1build1 - no-change rebuild.
• [2021-05-26] php-http-interop-http-factory-tests/0.9.0-1build1 - no-change rebuild.
• [2021-05-26] php-twig/3.3.2-1 - sync d from experimental.
• [2021-05-26] php-doctrine-cache/1.10.2-2ubuntu1 - fix build w/ PHP 8.
• [2021-05-26] php-symfony-contracts/2.4.0-1 - sync d from experimental.
• [2021-05-26] php-phpseclib/2.0.30-2ubuntu1 - fix build w/ PHP 8.
• [2021-05-27] php-email-validator/3.1.1-2 - sync d from experimental.
• [2021-05-27] php-async-aws-core/1.10.0-1 - sync d from experimental.
• [2021-05-27] php-async-aws-ses/1.4.0-1 - sync d from experimental.
• [2021-05-27] php-async-aws-sqs/1.5.0-1 - sync d from experimental.
• [2021-05-27] libphp-swiftmailer/6.2.4-1ubuntu1 - fix build w/ PHP 8.
• [2021-05-27] phpunit/9.5.4-1 - sync d from experimental.
• [2021-05-27] php-psr-cache/3.0.0-1 - sync d from experimental.
• [2021-05-27] php-psr-container/2.0.1-1 - sync d from experimental.
• [2021-05-28] php-wmerrors/2.0.0~git20190628.183ef7d-2ubuntu1 - fix build w/ PHP 8.
• [2021-05-28] php-monolog/2.2.0-1 - sync d from experimental.
• [2021-05-28] php-amqplib/3.0.0-1 - sync d from experimental.
• [2021-05-28] php-cache-lite/1.8.3-1 - uploaded to Debian.
• [2021-05-28] php-cache-lite/1.8.3-1 - sync d from experimental.
• [2021-05-29] php-symfony-contracts/2.4.0-1ubuntu1 - fix build w/ PHP 8.
• [2021-05-31] php-symfony-contracts/2.4.0-1ubuntu2 - fix build w/ php-cache-container.

MIRs:

• [2021-05-16] LP: #1915445/python-aws-requests-auth.
• [2021-05-20] LP: #1152187/systemd-container.
• [2021-05-31] LP: #1930207/prips.

Seed Operations:

• [2021-05-31] MP #403505/systemd-container for Bionic.
• [2021-06-01] MP #403562/prips for Impish.

---

Debian (E)LTS

Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years. Debian LTS is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success. And Debian Extended LTS (ELTS) is its sister project, extending support to the Jessie release (+2 years after LTS support). This was my twentieth month as a Debian LTS and eleventh month as a Debian ELTS paid contributor.
I was assigned 29.75 hours for LTS and 40.00 hours for ELTS and worked on the following things:

LTS CVE Fixes and Announcements:

• Issued DLA 2654-1, fixing CVE-2021-29472, for composer.
  For Debian 9 stretch, these problems have been fixed in version 1.2.2-1+deb9u1.
• Issued DLA 2655-1, fixing CVE-2021-22885 and CVE-2021-22904, for rails.
  For Debian 9 stretch, these problems have been fixed in version 2:4.2.7.1-1+deb9u5.
• Issued DLA 2656-1, fixing CVE-2021-3504, for hivex.
  For Debian 9 stretch, these problems have been fixed in version 1.3.13-2+deb9u1.
• Issued DLA 2659-1, fixing CVE-2018-10196 and CVE-2020-18032, for graphviz.
  For Debian 9 stretch, these problems have been fixed in version 2.38.0-17+deb9u1.
• Issued DLA 2662-1, fixing CVE-2021-32027 and CVE-2021-32028, for postgresql-9.6.
  For Debian 9 stretch, these problems have been fixed in version 9.6.22-0+deb9u1. This update for done by the maintainer, Christoph Berg. I just took care of announcing and publishing the update.
• Uploaded ruby-rack-cors to buster-security, fixing CVE-2019-18978. For Debian 10 buster, these problems have been fixed in version 1.0.2-1+deb10u1.
• Issued DLA 2663-1, fixing CVE-2021-22204, for libimage-exiftool-perl.
  For Debian 9 stretch, these problems have been fixed in version 10.40-1+deb9u1.

ELTS CVE Fixes and Announcements:

• Issued ELA 425-1, fixing CVE-2021-22885 and CVE-2021-22904, for rails.
  For Debian 8 jessie, these problems have been fixed in version 2:4.1.8-1+deb8u9.
• Uploaded rails to unstable, fixing CVE-2021-22885, CVE-2021-22902, and CVE-2021-22904.
  For Debian sid, these problems have been fixed in version 2:6.0.3.7+dfsg-1.
• Issued ELA 426-1, fixing CVE-2021-3504, for hivex.
  For Debian 8 jessie, these problems have been fixed in version 1.3.10-2+deb8u3.
• Issued ELA 428-1, fixing CVE-2018-10196 and CVE-2020-18032, for graphviz.
  For Debian 8 jessie, these problems have been fixed in version 2.38.0-7+deb8u1.
• Issued ELA 430-1, fixing CVE-2021-22204, for libimage-exiftool-perl.
  For Debian 8 jessie, these problems have been fixed in version 9.74-1+deb8u1.

Other (E)LTS Work:

• Front-desk duty from 24-05 until 30-05 for both LTS and ELTS.
• Triaged rails, libimage-exiftool-perl, hivex, graphviz, glibc, libexosip2, impacket, node-ws, thunar, libgrss, nginx, postgresql-9.6, ffmpeg, composter, and curl.
• Mark CVE-2019-9904/graphviz as ignored for stretch and jessie.
• Mark CVE-2021-32029/postgresql-9.6 as not-affected for stretch.
• Mark CVE-2020-24020/ffmpeg as not-affected for stretch.
• Mark CVE-2020-22020/ffmpeg as postponed for stretch.
• Mark CVE-2020-22015/ffmpeg as ignored for stretch.
• Mark CVE-2020-21041/ffmpeg as postponed for stretch.
• Mark CVE-2021-33574/glibc as no-dsa for stretch & jessie.
• Mark CVE-2021-31800/impacket as no-dsa for stretch.
• Mark CVE-2021-32611/libexosip2 as no-dsa for stretch.
• Mark CVE-2016-20011/libgrss as ignored for stretch.
• Mark CVE-2021-32640/node-ws as no-dsa for stretch.
• Mark CVE-2021-32563/thunar as no-dsa for stretch.
• [LTS] Help test and review bind9 update for Emilio.
• [LTS] Suggest and add DEP8 tests for bind9 for stretch.
• [LTS] Sponsored upload of htmldoc to buster for Havard as a consequence of #988289.
• [ELTS] Fix triage order for jetty and graphviz.
• [ELTS] Raise issue upstream about cloud-init; mock tests instead.
• [ELTS] Write to private ELTS list about triage ordering.
• [ELTS] Review Emilio s new script and write back feedback, mentioning extra file created, et al.
• [ELTS/LTS] Raise upgrade problems from LTS -> LTS+1 to the list. Thread here.
  • Further help review and raise problems that could occur, et al.
• [LTS] Help explain path forward for firmware-nonfree update to Ola. Thread here.
• [ELTS] Revert entries of TEMP-0000000-16B7E7 and TEMP-0000000-1C4729; CVEs assigned & fix ELTS tracker build.
• Auto EOL ed linux, libgrss, node-ws, and inspircd for jessie.
• Attended monthly Debian LTS meeting, which didn t happen, heh.
• Answered questions (& discussions) on IRC (#debian-lts and #debian-elts).
• General and other discussions on LTS private and public mailing list.

---

Until next time.
:wq for today.

It's a gross hack but works for now. To prevent overly sensitive mic settings autotuned by the browser in web conferences, I currently edit as root /usr/share/pulseaudio/alsa-mixer/paths/analog-input-internal-mic.conf. Change in [Element Capture] the setting volume from merge to 80. The config block as a whole looks like this:

[Element Capture]
switch = mute
volume = 80
override-map.1 = all
override-map.2 = all-left,all-right

Solution found at https://askubuntu.com/a/761103.

The dovecot version which will be released with bullseye seems to require some subtle config adjustment if you

• use ssl (ok that should be almost everyone)
• and you would like to execute doveadm as a user, who can not read the ssl cert and keys (quite likely).

I guess one of the common cases is executing doveadm pw e.g. if you use postfixadmin. For myself that manifested in the nginx error log, which I use in combination with php-fpm, as.

2021/04/19 20:22:59 [error] 307467#307467: *13 FastCGI sent in stderr: "PHP message:
Failed to read password from /usr/bin/doveadm pw ... stderr: doveconf: Fatal: 
Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 12: ssl_cert:
Can't open file /etc/dovecot/private/dovecot.pem: Permission denied

You easily see the same error message if you just execute something like doveadm pw -p test123. The workaround is to move your ssl configuration to a new file which is only readable by root, and create a dummy one which disables ssl, and has a !include_try on the real one. Maybe best explained by showing the modification:

cd /etc/dovecot/conf.d
cp 10-ssl.conf 10-ssl_server
chmod 600 10-ssl_server
echo 'ssl = no' > 10-ssl.conf
echo '!include_try 10-ssl_server' >> 10-ssl.conf

Discussed upstream here.